Ship the boring version first

Every project I have regretted began the same way: we knew the ambitious version, we could see it clearly, and we decided the plain version was beneath us.

The plain version is never beneath you. It is the instrument you use to find out whether the ambitious version is about the right thing.

The plain version answers a different question

An ambitious build answers can we make this good? A plain build answers does anyone want this at all? These look like the same question from inside a planning document and they are not remotely the same question, and only one of them can be wrong in a way that costs you a quarter.

The plain version is also the only version you can put in front of someone in a fortnight. Two weeks of real use will tell you more than two months of your own certainty.

What plain does not mean

Plain does not mean unfinished. A boring build still has working error states, real copy, and a considered empty state, because those are the parts that decide whether a person trusts it enough to keep going. Plain means fewer moves, each one complete.

Cut scope, not craft. A small thing done properly reads as confidence. A large thing done roughly reads as a prototype, and people evaluate prototypes differently — usually more harshly.

The interesting version gets cheaper

Here is the part that surprised me. When the plain version is live, the ambitious version stops being a design problem and becomes an editing problem. You are no longer inventing against a blank page; you are looking at something real and saying this bit is wrong, and I know why.

That is a much better position to design from, and you arrive at it faster by shipping something you were slightly embarrassed by.